Skip to content

soc: apple: sep: unmap the firmware IOVA, not the physical address - #592

Open
brentkearney wants to merge 1 commit into
AsahiLinux:asahi-wipfrom
brentkearney:sep-unmap-iova
Open

soc: apple: sep: unmap the firmware IOVA, not the physical address#592
brentkearney wants to merge 1 commit into
AsahiLinux:asahi-wipfrom
brentkearney:sep-unmap-iova

Conversation

@brentkearney

@brentkearney brentkearney commented Sep 2, 2026

Copy link
Copy Markdown

Unmap the IOVA that dma_map_resource() returned instead of the region's physical address, so unbinding apple_sep stops warning twice in the IOMMU and stops leaking the SEP firmware mapping. Closes #591.

Changes

  • Add fw_iova: Atomic<u64> to SepData, storing the return value of dma_map_resource() next to the existing fw_mapped flag.
  • Pass fw_iova instead of region_params.addr to dma_unmap_resource() in the unbind path.
  • Leave the bind and boot paths unchanged.

Testing

Compile-tested against asahi-7.1.6-1 with rustc 1.93.1, and runtime-tested on a MacBook Pro 16-inch 2021 (apple,j316s / apple,t6000) with the sep node enabled:

  • drivers/soc/apple/sep.o builds before and after, CLIPPY=1 introduces no new warnings, and rustfmt --check passes.
  • On the stock kernel, echo 396400000.sep > /sys/bus/platform/drivers/apple_sep/unbind produces the two WARNs in apple_sep: unbinding warns twice and leaks the firmware IOMMU mapping #591 and sets the W taint bit.
  • On the patched kernel, the same unbind logs nothing: dmesg | grep -c WARNING and dmesg | grep -c dart_unmap both return 0, and the W taint bit (512) stays clear.
  • On the patched kernel, the device's driver link is gone afterwards, so remove() ran to completion.

@brentkearney

brentkearney commented Sep 2, 2026

Copy link
Copy Markdown
Author

Runtime results from the patched kernel on the j316s (MacBook Pro 16-inch, 2021, apple,t6000):

  • apple_sep binds at boot, SEPOS completes the boot handshake and advertises its endpoints as before.
  • echo 396400000.sep > /sys/bus/platform/drivers/apple_sep/unbind completes with no kernel output at all. dmesg | grep -c WARNING → 0, dmesg | grep -c dart_unmap → 0. /proc/sys/kernel/tainted keeps the W bit (512) clear; on the stock kernel this same unbind emits the two WARNs in apple_sep: unbinding warns twice and leaks the firmware IOMMU mapping #591 and taints the kernel.
  • /sys/bus/platform/devices/396400000.sep/driver is gone after the unbind, so remove() ran to completion.

load_fw_and_shmem() maps the SEP firmware region with dma_map_resource(),
which returns an IOVA, but keeps only the shifted copy needed for the
MSG_BOOT_IMG4 message and discards the IOVA itself. remove() then calls
dma_unmap_resource() with region_params.addr, the physical address of the
reserved region.

The two are unrelated, so the unmap tears down page table entries that were
never present, and the real mapping is leaked. On t6000 the region sits at
0x10006340000, far outside the device's DART address space, and unbinding
the driver warns twice:

  WARNING: drivers/iommu/io-pgtable-dart.c:308 at dart_unmap_pages+0x11c/0x140
   dart_unmap_pages+0x11c/0x140
   apple_dart_unmap_pages+0x24/0x30
   __iommu_dma_unmap+0x94/0x140
   iommu_dma_unmap_phys+0xf8/0x118
   ...3sep9SepDriverEE20post_unbind_callback+0x34/0x70

  WARNING: drivers/iommu/dma-iommu.c:844 at __iommu_dma_unmap+0x128/0x140
   __iommu_dma_unmap+0x128/0x140
   iommu_dma_unmap_phys+0xf8/0x118
   ...3sep9SepDriverEE20post_unbind_callback+0x34/0x70

Keep the IOVA alongside the existing fw_mapped flag and unmap that instead.

Reproduced on an Apple MacBook Pro (16-inch, 2021), t6000/j316s, by
enabling the sep node and unbinding the driver.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant